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ABSTRACT 

This  Portable,  Reusable.  Integrated  Software  Modules  (PRISM)  Documentation  Library  Release 
1.0  Model  Document  was  created  by  the  Central  Archive  for  Reusable  Defense  Software 
(CARDS)  Program  to  help  disseminate  PRISM  documentation  and  knowledge.  It  represents 
the  current  state  of  the  PRISM  Elocumentadon  Library  Model.  It  is  a  'living’  document  and  will 
be  updated  with  every  Library  release. 

This  document  describes  library  modeling  and  examines  modeling  concepts  and  specializa¬ 
tion/aggregation  hierarchies.  This  document  is  specific  to  PRISM  Documentation  Library  Model 
Release  1.0  in  its  description  of  document  types,  actual  documents  available  and  future  direction 
of  this  model.  The  intended  audience  is  anyone  desiring  an  understanding  of  the  PRISM  Docu¬ 
mentation  Library  Model  and  wanting  a  descripticm  of  this  current  Ubrmy  release.  The  reader 
should  have  an  understanding  of  CARDS  and  PRISM. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704-0188 


Puouc  rtvontne  ourovn  tor  inn  coiiKtion  of  intormaiion  n  ntimotM  to  «<ofoqc  >  nour  per  meonte.  inciuoing  tnr  time  tor  rcviowmq  inttrumont.  tcarcninq  •intm^  a*M  lourcn. 
gainonnq  ano  maintaining  Iho  oata  newad.  and  comeltting  ano  raviaming  tne  tollKlion  of  inf ormaiion  Send  (ommenn  rcoarding  thn  buroan  atiimaie  O'  any  oinar  aioatt  of  inn 
coiiaction  of  mtormaiion.  iiKiuoing  luggoMiom  for  raducing  tnn  ouroan  lo  tvatningion  Haodouanan  Sarvicai.  Oiraaorata  tor  information  Ooaraiiont  and  Raoont.  i  jlS  Jaffarwn 
Oavn  Hignway.  Suita  1204  Ailingion.  VA  22202-4302.  and  to  ina  Offica  of  Managamant  and  tudgat.  ^aoarwora  Kadumon  Proiaa  (07044)180).  Wayungton.  OC  20S03 


T.  AGENCY  USE  ONLY  (Ledv«  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  ANO  OATES  COVERED 

3  December  1993  Informal  Technical  Report 


4.  TITLE  ANO  SUBTITLE  S.  FUNDING  NUMBERS 

Portable  Reusable  Integrated  Software  Modules  (PRISM) 

Documentation  Library  Model  -  Release  1.0 

(CARDS)  F19628-93-C-0130 

6.  AUTHOR(S) 

Aleisa  Petracca 
Les  Hayhurst 

George  Jackelen _ 


7.  PERFORMING  ORGANIZATION  NAME(S)  ANO  AOORESS(ES)  8.  PERFORMING  ORGANIZATION 

Unisys  Corporation  number 

12010  Sunrise  Valley  Drive  STARS-VC-B015/000/00 

Reston,  VA  22091 


9.  SPONSORING /MONITORING  AGENCY  NAME(S)  ANO  AOORESS(ES) 

Department  of  the  Air  Force 
Headquarters  Electronic  Systems  Center 
Hanscom  AFB,  MA  01731-5000 


10.  SPONSORING /MONITORING 
AGENCY  REPORT  NUMBER 


12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 

Distribution  "A" 


12b.  DISTRIBUTION  CODE 


13.  abstract  (Maximum  200  words) 


Please  see  Abstract  page. 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

Unclassified 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

Unclassified 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

Unclassified 


IS.  NUMBER  OF  PAGES 

32 


16.  PRICE  CODE 


20.  LIMITATION  OF  ABSTRACT 


NSM  ’SCO-OI -280-5500 


5tanoara  ^orm  298  (Rev  2-89' 


CDRL:  BOIS 
3  December  1993 


Table  of  Contents 


1  Introduction.^. 


1.1  CARDS  Library  System  History.... 


12  Summary  History  of  Changes.. 


2  Domain  Engineering  and  Library  Modeling..... 


2.1  Scoping  CARDS  Repositories.............^......... 

2.2  ^^^Uftl^S  Rlethodology ............................... ............ 

23  AdaKNET _ _ 

2.3.1  Spccialiimtion ...............  ........................... ........I 


2J.2  Aggregation.... 

233  The  ModelM.»..M...MM< 
23.4  Inferendng........... 

233  Actions..... 


3  PRISM  Documentation  Library  Model.. 


3.1  Scope  of  the  PRISM  Documentation  Library  Modd........ 

33  Background^.. 

33  PRISM  Documentation  Model  Access 
3.4  PRISM  Documentation  Library  Model  Structure.......^......... 

3.4.1  Architecture  Report.^..... 

3.43  Demonstration  Report.^.............. 

3.4.2.1  July  1992  Proof  of  Concept  Prototype  Report......... 

3.4.23  November  1992  Proof  of  Concept  Prototype  Repent................... 

3.43  Quarterly  Dememstration  Report  (QDRs)..........................^................ 


444444 44 44 44 ••••••••••••#•••••«• *444 444 44 44 44444 44 44 44 44444 44444444 444 44 44 4444 41 


444»>4444 444444444 444444444444444444 44 444 


444444444444444444444 


3.4.4  Process  Report  444444' 

3.4.4.1  Five  Year  Plan 


1444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444 


444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444 


3.4.43  Qualification  Methodology  Report 
3.4.43  Reusability  Process.. 

3.43  Product  Assessment  Report  (PARs)......^...... 

3.43.1  AMHS  Evaluation........... 

3.433  Contessa  Evaluation..... 

3.433  DBAIS  Evaluation  ...............................I 

3.43.4  GIS  Evaluation........... 


44444444444444444444444444444444444444444444444444444444444 


4444444444444444444444444444444444444444444444444444444  U 44 44 44444444444444444* 


44444444444444444444444444444444444444444444 


>44444444444444444444' 


>44 44 44 444 44 44 444444444 44 44 44444 44 44 44 444 44 44 44 4444444 44 44 444444444 44 44444 44 44 44 44 44444 44# d 


>44444 44 44 44 444 4444 44 44 444 4444 44 44 4444444 4444 444 44 44 44 44 444 4444 44 44  J 


>444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444. 


CDRL:  B015 
3  December  1993 


3.4.5  J  Interprocess  Communication  (IPC)  Evaluation 

3.4.5.6  Low  to  High  Guard  Evaluation... 

3.4.5.7  MTV  Evaluation...^. _ ..... _ _ 

3.4.5.8  Network  Monitor  Evaluation. 

3.4.5.9  Night  Hawk  Guard  Evaluation 

3.4.5.10  Secure  LAN  Evaluation... 


'••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••Ml 


19 

- 19 

.19 
.19 


•M  ••••••••  M^MM^^**^i 


•  ••M^M*«^*^*^«M«MM^^M*M» 


3.5  Future  Directions/Enhancements 

3J:.l  Structural  Changes... _ _ 

3.5.2  Action  Changes 


•  ♦••••  •••••••  >••••>•! 


•  ••••M^^«««**>t  >>>•■••••••  •••••••••••M^^^^^^»^^M« 


•  •>••>•••♦•••••••••»< 


.19 

19 


19 

'•MMM* 

..........  19 

_ 19 


Appendices 


Appendix  A  Bibliography....... 


_ A .  1 


Appendix  B  Glossary  of  Terms  and  Acronyms _ ....... _ .............. 


............ ...... B  *  1 


Terms.... 
Acronyms..... 


I  •••••«••••••«  •••••••M*«M^^^M«^^^M*M««««MM«MMM^«*««M*«M*«M*«*M**M»**MMMMMi 

'•••••♦•••••••••••»a«»^«Mi»^— •••••••♦M*— »♦••»♦»••»••»•••••••>#»•••••••♦»•  •♦MM»«e^*i 


••••♦••••••  ••MMM»M—MMM^O» 


B.l 

B.3 


Appendix  C  Library  Actions..... 


C-1 


CI»L  ;  B015 
3  DecembCT  1993 


List  of  Figures 


Fig.  2-1 
Fig.  2-2 
Fig.  2-3 
Fig.  2-4 
Fig.  2-5 
Fig.  2-6 
Fig.  3-1 
Fig.  3-2 
Fig.  3-3 
Fig.  3-4 
Fig.  3-5 


ftiid  ^^omsuii  En^ificcrm^  occssfs— ——3 
Implementation  Based  Reuse 
Architecture  Based  Reuse. 

Domain  Based  Reuse 
Specialixation  Hierarchy*— 

^^SSre^[ation  Hierarchy *————— —**•*********«—————**»——***—*«******—****———*****—*——**— 10 

PRISM  Documentation  Model  Top-Levd  View  *  **———*————*»*——**— **——***——*  14 

Architecture  Report  and  Its  Child  *****»****—»—*—****♦*»*■****»************—»***—****■*■**——**—***  15 
DemcMistration  IKeport  and  Its  C^hildren**— —•—•IS 
I^rocess  ^leport  and  Its  ^^hildren*  ****•*******»—————*******>*—*—**■*—*****■***»•■****—*•——  Id 

Product  Assessment  Report  and  Its  Children  17 


STARS- VC-BOISAXXVOO 


3  December  1993 


1  Introduction 

This  document  describes  the  Portable  Reusable  Integrated  Software  Modules  (PRISM)  Docu¬ 
mentation  Library  (PDL)  Release  1.0  Model  created  by  the  Central  Archive  for  Reusable  Defense 
Software  (CARDS)  Program.  The  PDL  is  an  encoding  of  all  available  PRISM  documents,  the 
documents’  hierarchy,  and  chronological  release  tnder.  The  PDL  will  be  enhanced  to  reflect 
new  information,  new  documentation,  and  new  releases  of  existing  documentation.  Releases  of 
the  PDL  will  include  updates  to  this  document 

The  purpose  of  this  Document  is  to: 

•  Describe  the  PDL. 

•  Describe  how  the  PDL  model  is  related  to  the  CARDS  Command  Center  Library 
(CCL)  model,  to  CARDS,  and  r j  related  PRISM  projects. 

•  Provide  the  reader  with  an  understanding  of  modeling  concepts  used  to  represent  the 
PDL. 

Section  2  provides  a  description  of  library  modeling,  specifically  the  Reuse  Library  Framework’s 
(RLF’s)  capabilities  and  fimctions,  which  may  be  skipped  if  you  are  familiar  with  the  topic. 

Section  3  discusses  the  scope,  background,  history,  and  model  structure  of  the  PDL.  How  the 
PDL  graphically  appears  to  the  user  is  shown. 

Appendix  A  is  a  bibliography  of  sources  used  to  compile  this  Document 
Appendix  B  is  a  glossary  of  terms  and  acronyms  used  within  this  Document 
Appendix  C  is  a  list  of  actions  contained  within  the  PDL. 

Terms  having  a  specific  technical  meaning  are  bffid  the  first  time  they  are  used  and  appear  in 
the  glossary.  Names  of  elements  of  a  model  (such  as  concepts,  relationships  and  inferencers) 
appear  in  bold  itaUc.  Some  emphasized  words  appear  in  italic. 

1.1  CARDS  Library  System  History 

The  current  primary  source  for  information  about  command  centers  is  PRISM.  CARDS  relies 
on  PRISM  for  command  center  models,  evolution  information,  command  center  domain 
components,  and  command  center  domain  documentation.  The  CARDS  library  mission  is  to 
establish  a  model-based  library  of  command  center  components  and  information,  to  acquire 
commercial-ofif-the-shelf  (COTS)  and  Government-off-the-shelf  (GOTS)  components,  and  to 
qualify  the  CX)TS  and  GOTS  for  inclusion  into  the  command  center  libraries. 

CARDS  has  created  two  libraries  (which  will  be  updated,  as  required,  to  include  new 
information): 
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1.  The  CCL  is  a  model-based  library  of  command  center  components  and  infmmation. 
CX>TS  and  GOTS  components  are  acquired  and  qualified  for  inclusion  in  the  com¬ 
mand  center  domain.  CARDS  obtains  command  center  architecture  from  the 
PRISM  models  and  components;  and  in  turn,  PRISM  uses  the  CARDS  CCL  to  sup¬ 
port  and  further  prove  the  feasibility  of  integrating  software  components  for  use  in 
the  command  center  domaiiL 

2.  The  PDL  incA,.Jes  PRISM  development  documentation  and  demonstrations.  The 
PDL  was  developed  to  support  both  CARDS  and  PRISM.  PRISM  documentatitxi 
includes  software  reuse  process  information  which  is  domain  independent 
Therefcne,  the  PDL  warrants  its  own  mod  .1  apart  from  the  CCL. 

Since  the  CCL  and  PDL  are  so  closely  related,  some  of  the  entities  in  the  PDL  may  cross  over 
into  the  CCL,  where  necessary.  One  entity  that  does  cross  over  from  the  PDL  into  the  CCL  is 
the  Product  Assessment  Report  (PAR);  thus  PARs  appear  in  both  the  C(X  and  PDL.  Therefore, 
there  are  two  independent,  but  command  center  related,  libraries  in  the  CARDS  System  Library: 
the  CCL  and  PDL. 

1,2  Summary  Histwy  of  Changes 

Since  this  is  the  first  release  of  the  PDL,  there  have  been  no  changes  to  any  previous  release. 
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2  Domain  Engineering  and  Library  Modeling 


CARDS  views  a  library  as  a  library  model  and  a  set  of  i^licaticms.  The  acquired  knowledge  can 
be  fully  represented  when  harnessed  by  a  model  in  some  formalism.  The  RLF  is  the  mechanism 
being  used  to  implement  models.  RLF  integrates  a  knowledge  representation  scheme,  rule-based 
inferencing  and  a  graphical  browser.  The  descriptiai  of  the  nature  of  the  model  requires  an 
overview  of  the  encoding  mechanisms. 

Although  reuse  may  be  approached  in  a  variety  of  informal  ways,  CARDS  position  is  that  a 
formal,  systematic  integration  of  reuse  into  the  conventional  software  development  process  yields 
substantially  greater  rewards.  The  basis  for  this  increased  formality  is  the  emerging  disciplines  of 
domain  analysis  and  donudn  engineering.  Figure  2-1  illustrates  the  correspondence  reladsoiships 
between  aspects  of  domain  engineering  and  software  engineering.  The  current  state  of  research 
and  practice  of  domain  analysis  and  domain  engineering  are  well  represented  in  an  THEE  tutorial. 
Domain  Analysis  and  Software  Systems  Modeling  [PRIE92].  The  key  points  are: 

•  Domain  engineering  targets  a  well-defined  applicadtm  area  (or  donudn)  and  results 
in  the  creation  of  various  products  characterizing  this  domain  (e.g.,  the  donudn 
model). 

•  A  key  step  in  domain  engineering  is  domain  analysis,  which  is  roughly  analogous  to 
software-engineeting  requirements  analysis  except  that  domain  analysis  describes 
the  requirements  of  a  family  of  systems  (ie.,  the  requirements  of  the  domain),  while 
software-engineering  requirements  aiuilysis  focuses  on  the  needs  of  a  particular 
system  in  question. 

A  domain  model  may  encompass  not  just  the  results  of  the  domain  analysis  (as  just  defined), 
but  in  addition  include  other  aspects  of  the  domain  as  well,  including  a  generic  architecture  for 
systems  within  the  domain,  and  reusable  components  satisfying  the  conditions  of  the  generic 
architecture. 

This  itemization  is  not  meant  as  a  precise  and  fixed  definition  of  domain  engineering  (since  this 
is  a  still-emerging  discipline),  but  rather  as  a  basis  for  understanding  the  relationship  of  CARDS 
libraries  to  both  domain  engineering  and  software  engineering  processes.' 

Note  that  in  the  above  summary  the  terms  domain  analysis,  domain  model  and  genoic 
architecture  are  used,  but  the  terms  library  model  and  library  modeling  are  conspicuously  absent 
The  reason  for  distinguishing  library  models  and  modeling  from  domain  models  and  modeling 
is  twofold: 

'  For  example,  it  is  not  universally  accepted  that  the  purpose  of  domain  analysis  is  merely  domain 
oriented  requirements  analysis. 
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Figure  2-1  Software  and  Domain  Engineering  Processes 

•  Since  CARDS  is  meant  to  provide  a  generic  capability  for  constructing 
domain-specific  reuse  libraries  [STARS93b],  it  is  important  that  CARDS  does  not 
preemptively  select  one  set  of  domain  engineering  techniques  at  the  expense  of  oth¬ 
ers.  Since  different  applicatiem  domains  (and  different  Dq>artment  of  Defense  (DoD) 
programs)  may  be  best  served  by  different  domain  analysis  and  domain  modeling 
techniques,  any  such  CARDS  selection  would  be  premature  and  counterproductive. 

•  The  decision  of  which  domain  engine^ing  by-products  to  capture,  and  how  to  repre¬ 
sent  them,  is  a  design  decision  based  not  only  upon  the  nature  of  the  domain  and 
the  domain  engineering  analysis  techniques  used,  but  also  on  the  anticipated  use  of 
these  products  during  software  engineering.  That  is,  the  reuse  repository  acts  as  an 
integrating  agent  between  domain  engineering  and  software  engineering  processes. 
The  form  this  integrating  agent  (i.e.,  the  repository)  needs  to  take  is  dependent  upon 
both  endpoints  of  the  integration  relation  -  domain  engineering  and  software 
engineering.  This  point  is  elaborated  in  the  following  section. 


2.1  Scoping  CARDS  Repositories 


It  is  possible,  as  in  Figure  2-2,  to  scope  the  reposiuxy  to  capture  only  the  reusable  components 
produced  as  a  result  of  the  implementation  phase  of  domain  engineering  processes.  In  Hgure 
2-2  this  scoping  is  denoted  as  a  parts  library.  The  utility  of  parts  libraries  without  including 
some  form  of  architectural  context  may  seem  limited,  but  can  be  justified  in  cases  where  the 
domain  architecture  is  unstable  (i.e.,  still  undergoing  technolo^cal  evolution  or  standardization), 
or  where  a  relatively  small  number  of  components  in  the  library  would  not  justify  the  investment 
in  maintaining  an  up-to-date  architectural  desciiptitm.  Note  in  Figure  2-2  that  reusable  parts  can 
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be  ’used*  during  system  implementation,  but  that  an  ‘understanding’  of  what  parts  are  available 
in  a  repository  can  aid  in  system  specification. 


Figure  2-2  Implementation  Based  Reuse 

In  Figure  2-3  the  scope  of  the  repository  has  been  extended  to  encompass  the  reusable  components 
as  well  as  an  architectural  model  capturing  the  relationships  among  the  components,  and  describes 
the  purpose  of  the  components  within  an  overall  system.  One  advantage  of  such  a  library,  denoted 
as  generic  architecture  library  in  Figure  2-3,  is  that  the  additional  context  informatkm  provided 
for  reusable  components  can  support  the  automatic  composition  of  systems  or  parts  of  systems. 
For  example,  if  a  component  implementing  part  of  a  database  subsystem  was  selected  for  use 
in  an  syiplication,  the  generic  architecture  would  provide  the  basis  for  the  automatic  selectitm 
and  retrieval  of  any  components  implied  by  the  selection  of  the  original  ctnnpcxient  (e.g.,  SQL 
interface  code  peculiar  to  a  particular  relational  database  vendcn*). 

In  addition,  a  genetic  architecture  library  can  make  the  browsing  and  searching  of  large  libraries 
simplo*  and  more  meaningful  to  engineers  than,  for  example,  faceted  classificatitxi  schemes 
requiring  strict  usage  of  library-specific  keywords.  Note  that  in  Figure  2-3  the  addition  of  genetic 
architecture  information  in  the  library  model  extends  the  ’use’  relation  to  include  both  system 
specification  and  implementation,  while  requirements  analysis  can  be  aided  by  ’understanding’ 
the  architecture  supporting  applications  within  a  domain. 

Figure  2-4  extends  the  scope  of  the  repository  to  encompass  all  of  the  by-products  of  domain 
engineering.  This  additional  scoping  broadens  the  focus  of  the  reuse  library  to  incotporam 
domain  variance  as  well  as  dcnnain  commonality.  While  generic  architectures  focus  on  what 
is  the  same  across  iq)plications  in  a  domain,  a  domain  model  also  captures  differences  across 
applicatitms  in  a  domain.  This  broadened  focus  can  support  the  cq)ture  of  design  ratkHude  for 
alternative  designs  of  the  underiying  generic  architecture;  this,  in  turn,  would  be  instrumental 
for  evolving  the  domain  architecture  in  response  to  new  technology  and  new  demands  on  the 
previously  devel(q)ed  applicatimis. 
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Figure  2-3  Architecture  Based  Reuse 

In  Figure  2-4  the  advantages  of  a  domain  model  library  are  shown  both  by  illustrating  the  ’use’ 
relationships  present  throughout  software  engineering  processes,  and  by  illustrating  the  potential 
feedback  loop  from  software  engineering  to  the  domain  model.  This  is  done  by  capturing  the 
variations  of  each  successive  system  developed  from  the  reuse  library  and  why  these  systems 
varied. 


Figure  2-4  Domain  Based  Reuse 
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2J  CARDS  Methodtriogy 


CARDS  views  a  library  as  a  library  model  and  a  set  of  applications,  and  the  construction  of 
a  library  model  as  a  design  activity  balancing  various  requirements.  What  goes  into  and  what 
comes  out  of  a  library  is  dependent  upon  the  library  modeling  formalism  used,  the  kind  of 
domain  analysis  conducted,  and  the  kind  of  library  applications  needing  to  be  constructed  u 
support  the  anticipated  system  engineeting  processes.  The  library  model  includes  informatkir 
in  addition  to  that  dmived  from,  or  pertinent  to  dranain  analysis  [STARS93b]. 

There  are  two  approaches  to  implementing  a  reuse  library: 

•  Component-based  libraries  are  organized  around  a  collection  of  reusable  compo¬ 
nents.  The  underlying  operational  concept  is  that  of  search  and  retrieval  of 
individual  components.  Components  found  in  such  libraries  are  classified  in  broad, 
generalized  categories.  Model-based  libraries  use  domain  models  as  a  foundafitm 
for  library  organization  and  a  framewoiic  for  supporting  applications  exploiting 
these  models  to  autranate  various  library  services. 

•  Model-based  libraries  encompass  information  such  as  domain  knowledge,  generic 
architecture  specifications,  requirements,  and  implementation  restrictions,  as  well  as 
software  artifacts  [STARS93b]. 

One  of  the  visible  efforts  of  library  analysis  is  that  of  organizing  the  storage  and  retrieval  of 
the  reusable  components.  CARDS  approach  is  fundamentally  model-based  (the  motivatirat  has 
more  to  do  with  the  retrieval  of  components,  and  with  the  capture  of  reusable  information  that  is 
lost  in  component-based  libraries,  than  with  storage).  The  idea  is  that  one  of  the  major  obstacles 
to  reuse  is  the  difficulty  potential  reusers  have  in  locating  reusable  products.  Models  are  a  very 
powerful  mechanism  for  organizing  components  and  facilitating  user  access  to  them. 

A  CARDS  model  is  a  representation  of  a  specific  type  of  iq)plicati(m  area  (often  referred  to  as 
a  domain)  which  is  simply  a  limited  subject  area.  Because  it  mirrors  the  organization  of  the 
part  of  the  real  world  using  the  components  being  stored,  it  provides  a  means  of  organizing  and 
accessing  a  store  mechanism,  (jomponents  are  ’attached*  u>  the  moctel  in  the  spots  representing 
their  use  in  real  world  applicatitms.  The  fact  that  it  mirrors  the  application  area  makes  it  a  natural 
way  for  the  user  to  locate  the  components  they  are  interested  in.  This  user  friendliness  is  one 
of  the  main  motivations  for  organizing  the  repository  storage  and  retrieval  around  the  model. 

The  other  motivation  is  that  the  model  is  the  starting  point  for  potentially  many  powerful  tools 
to  aid  the  user  in  reuse  related  activities.  Because  the  model  is  ’computationally  accessible’ 
and  is  a  detailed  picture  of  what  is  involved  in  the  domain,  it  is  an  excellent  starting  point  for 
building  tools  that  can  ’reason’  about  the  various  elements  involved  in  the  dtmiain,  including 
the  specific  components  being  stored  in  the  library.  Inference  engines  are  used  to  atudyze  the 
information  enco^  in  the  model  and  tqtply  various  types  of  understanding  to  produce  results 
such  as  software  configuration. 
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2J  AdaKNET 


RLF  has  a  knowledge  representation  scheme,  called  AdaKNET,  facilitating  the  classification  of 
library  cmnponents.  AdaKNET  can  be  thou^t  of  as  a  graph  where  the  nodes  represent  general 
categories  or  specific  objects,  and  the  edges  represent  relationships  between  die  nodes.  Nodes, 
representing  general  classes  of  knowledge,  are  called  concepts  or  categories.  There  are  two  basic 
types  of  relationships,  spedalization  (’is*a’)  and  aggr^tion  ('has-a*),  described  below.  Two 
kinds  of  hierarchies  are  built  with  the  concepts  and  relationships:  specializatitm  and  aggregation 
hierarchies. 


23.1  Spedalization 


There  is  exactly  one  specialization  hierarchy  in  any  given  ’moder.'  The  specialization  hierarchy  is 
a  way  of  defining  the  concepts.  It  can  be  thought  of  as  a  glossary  and  can  be  compared  to  the  need 
to  declare  variables  in  a  traditional  computer  programming  language.  The  top  level  concq)t  is 
usually  given  a  very  generic  name,  such  as  thing  or  entity,  and  all  other  concepts  are  defined  to  be 
specializations  of  it  This  hierarchy  is  made  by  asserting  that  the  ’is-a*  unidirectional  relationship 
holds  between  two  ccmcepts,  i.e.,  less_general_eoncept  specializes  more_genenil_eoneept.  Or, 
less_general_eoncept  is-a  more_generaljeoncept. 

As  depicted  in  Figure  2-5,  animal  specializes  thing,  mammal  specializes  animal,  and  cow 
specializes  mammal.  The  modeler  can  build  a  set  of  concepts  representing  the  parts  of  the 
domain  needing  to  be  referenced.  In  this  view,  concepts  are  represented  as  a  single  oval  and 
the  specializatitm  links  are  represented  as  double  lined  arrows.  A  concept  represents  abstract 
categories  of  concise  things  and  may  also  be  called  a  generic  concept,  a  category  ot  a  class. 

The  specialization  hierarchy  provides  the  vocabulary  for  an  AdaKNET  model.  Because  every 
concept  in  the  model  is  defined  in  this  hierarchy  as  being  a  specialization  of  some  other  concq)t, 
we  have  a  way  of  understanding  the  context  of  any  concept  encountmed  in  the  model. 

Within  the  specialization  hierarchy,  the  tt^-level  node  is  very  generic  and  bectmies  mme 
and  more  specific  at  each  level  until  finally  the  leaf  nodes  may  contain  specific  examples  of 
their  parent  concepts.  A  leaf  node  representing  a  particular  component  or  elemental  piece  of 
inftmnation  instantiated  from  its  parent  concept  is  known  as  an  individual  or  object.  It  also 
may  be  known  as  an  individual  concept,  or  an  instance. 

Individuation  is  the  relationship  between  a  parent  concept  and  the  instantiation  (individual)  of  that 
parent  concq>L  Individuatitm  lies  within  the  specialization  hierarchy  and  defines  an  individuation 
link  between  a  concept  and  an  individual. 

’Model  is  a  word  potentially  having  a  very  specific  meaning  when  used  in  a  very  narrow  context, 
but  is  often  used  somewhat  loosely.  It  is  used  in  a  vmy  general  way  in  this  document 
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Hgure  2-5  Specialization  Hierarchy. 

Referring  to  Hgure  2-5,  note  the  individual  concqit  called  *Bossie\  In  this  example,  ‘Bossie’ 
is  our  specific  cow.  Yet,  *Bossie’  is  but  one  of  an  infinite  number  of  possibilities  far  an  instan¬ 
tiation  of  the  concept  cow.  As  shown  in  this  Hgure,  individuals  are  represented  as  double  ovals 
and  the  individuation  link  is  represented  as  a  three  lined  arrow. 


23.2  Aggregation 


Each  of  the  concepts  in  the  specialization  hierarchy  may  have  relationships  of  the  ’has-a’  nature 
with  any  other  concept  in  the  model,  including  itself.  These  relationships  may  express  attributes, 
characteristics,  features,  functional  capabilities,  requirements  or  metrics;  any  relationship  existing 
between  two  concepts  which  is  not  a  specialization  relationship.  Since  any  crmcept  may  have 
aggregation  hierarchy  under  it,  and  it  is  not  required  that  all  the  units  of  aggregatirm  structure 
tie  together,  the  model  usually  contains  many  separate  pieces  of  aggregation  hierarchy.  While 
every  concept  must  appear  in  the  specialization  hierarchy,  it  is  not  necessary  for  every  crmcept 
to  be  involved  in  an  aggregation  relationship. 

The  aggregation  hierarchy  is  built  by  beginning  with  the  concept  representing  the  thing  being 
modeled,  such  as  commandjcenter,  and  listing  all  of  its  ’has-a’  relationships.  These  relationships 
show  substructure,  characteristics  m  other  sorts  of  relationships  and  are  often  called  roles.  Each 
of  these  relationships  has  a  name,  type  and  range.  The  type  is  the  concqrt  being  pointed  to.  The 
range  is  an  ordered  pair,  zero  to  infinity,  or  some  narrower  specification,  including  a  converged 
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range  such  as  2  to  2.  This  value  represents  how  many  copies  of  that  relationship  mayAnust  exist 
simultaneously. 

Each  concept  automatically  inherits  the  aggregation  relationships  of  its  ancestors  in  the  special- 
izatimi  hierarchy.  AdaKNET  supports  multiple  inheritance;  so  a  concept  having  more  than  one 
patent  inherits  the  aggregation  relationships  of  each.  The  range,  and  the  possible  values  of  the 
type,  may  be  narrowed  on  subsequent  levels  of  tlw  hierarchy  (by  the  concepts  inheriting  them) 
to  support  the  logical  structure  of  the  aggregation  hierarchy.  This  is  called  role  restriction. 

Referring  to  Figure  2-6,  notice  that  the  individual  ‘Bossie*  has  what  is  known  as  a  filler  satisfying 
its  predecessor’s  inherited  relationship  of  makes jnUk  to  the  type  milk.  Individuals  must  have 
such  aggregational  relationships  to  other  individuals.  In  this  case  the  individual  type  is  ‘Bossie’s 
milk’  which  is  an  individuation  of  the  concept  mUk. 

In  this  PDL,  aggregation  relationships  are  not  represented.  To  include  this  representation  entails 
determiiung  how  each  document  is  related  to  other  documents,  or  how  each  document  affects 
or  is  affected  by  other  documents.  Analysis  of  this  type  has  currently  not  been  dcme;  however 
future  releases  of  models  may  include  ‘has-a’  links. 


Figure  2-6  Aggregation  Hierarchy 


233  The  Model 

These  two  types  of  hinarchy  are  completely  intertwined.  In  most  cases  what  the  modeler  and 
the  end  user  think  of  as  ’tire  model’  is  actually  a  subtree  (really  a  subgraph,  but  it  is  generally 
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thought  of  as  a  tree)  rooted  at  the  concept  representing  the  thing  to  be  modeled  and  all  the 
aggregation  hierarchy  under  it. 

A  full  model  includes  much  more  than  the  structural  organization  expressed  in  AdaKNET;  with 
the  inferencers,  discussed  below,  being  the  most  important  other  part  However,  in  this  Docu¬ 
ment  the  focus  is  on  the  structural  part  of  the  model.  This  is  because  the  structure  is  the  aspect 
that  is  most  usefully  described.  Discussing  why  the  structure  was  organized  as  it  was  commu¬ 
nicates  something  about  the  modeler’s  understai^ing  of  the  PRISM  documentation  domain.  In 
contrast,  the  inferencers  are  aids  for  accomplishing  tasks.  Their  actual  implementation  is  irrel¬ 
evant  to  the  end  user. 

23.4  Inferencing 

There  are  two  inference  engines  associated  with  AdaKNET: 

•  AdaTAU  was  written  in  conjunction  with  AdaKNET  and  is  a  part  of  the  RLE.  It  is 
tighdy  integrated  with  the  Graphical  Browser. 

•  CLIPS  (C  Language  Integrated  Production  System)  [GIAR92]  is  used  in  inferencing 
tools  working  on  the  AdaKNET  structure.  CLIPS  was  developed  for  the  National 
Aeronautics  and  Space  Administration  (NASA)  and  is  available  for  a  very  moderate 
fee,  or  ficee  for  use  on  Air  Fence  or  NASA  projects. 

These  two  inference  engines  provide  similar  basic  capabilities,  but  CLIPS  is  more  computation¬ 
ally  powerful  and  also  has  the  capability  of  querying  the  AdaKNET  model  structure. 

Both  inference  engines  permit  the  modeler  to  write  inferencers,  units  of  code  expressed  as  rules 
about  the  model.  These  units,  sometimes  called  rule-bases,  are  associated  with  specific  concepts 
in  the  AdaKNET  model. 

In  this  PDL,  neither  inference  engine  is  implemented.  In  the  PRISM  documentation  domain, 
there  is  no  apparent  necessity  for  inferencers,  since  PRISM  documents  are  neither  dependent 
up(H)  each  other  nor  mutually  exclusive  from  each  other. 

233  Actions 

Any  executable  program  or  process,  called  an  ’action’,  may  be  associated  with  any  concept  by 
the  creatOT  of  the  library.  The  mechanism  of  invoking  an  ’action’  at  a  concept  is  typically  used 
to  view  textual  information  associated  with  the  concept,  but  has  general  applicabiliQr  to  a  wide 
variety  of  needs. 

Actions  can  be  thou^t  of  as  strings  executed  in  an  operating  system  when  the  action  is  invoked. 
Action  ’targets’  are  the  strings  representing  the  object  upon  which  the  action  acts. 

Fot  example,  a  file  describing  PRISM  process  reports  may  be  viewed  at  the  categray 
process_report  by  including  an  action  which  executes  the  command: 
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preview  process_repon_desc.txt 

In  this  example,  ’process_report_desc.txt’  is  the  action  target  The  same  action,  with  a  differ¬ 
ent  action  target,  may  be  made  available  at  the  category  arehUecture_report  which  executes  the 
command: 

preview  architcture_report_desc.txt 

Actions  are  inherited  by  concepts  in  much  the  same  manner  as  roles.  All  subconcepts  subsumed 
by  a  concept  declaring  an  action  has  that  action  available.  Actions  can  also  be  inherited  along 
several  specialization  links  in  the  case  of  multiple  inheritance. 

Actions,  again  much  like  roles,  can  also  be  restricted  at  subconcepts  below  the  concept  where 
they  are  declared.  Action  targets  can  be  renamed  at  subconcepts,  regardless  of  inheritance. 
Appendix  C  provides  more  information. 
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3  PRISM  Documentation  Library  Model 

3.1  Scope  of  the  PRISM  Documentation  Library  Model 

The  PDL  Model  includes: 

•  PRISM  documents  pertinent  to  the  command  center  domain  and  architecture 
(distribudtxis  "A"  and  "C"). 

•  Documents  about  COTS  and  GOTS  components  that  were:  developed,  tested,  as¬ 
sessed,  certified  by  PRISM  to  be  qualified  by  CARDS,  and  placed  within  the 
command  center  architecture. 

•  Documents  about  the  PRISM  process  itself. 

3J  Background 

The  Generic  Command  Center  (GCQ  project  (the  forerunner  of  PRISM)  integrated  components 
for  use  in  command  centers.  From  the  G(X  Phase  2  Prototype  Summary  Report,  January  1992 
[ESD92]: 

"The  Generic  Command  Center  Phase  2  prototype  is  an  implementation  of  a  portion 
of  the  Generic  Command  Center  (GCC)  architecture.  The  purpose  of  this  prototype 
is  to  validate  the  concept  of  building  command  centers  by  integrating  large  reusable 
components.  The  required  functionality  is  that  of  processing...  messages;  establishing  a 
database:  displaying  irrformation  in  a  geogrcqyhic  irformation  system;  creating  tables  of 
information;  and  creating  briefings  that  interfere  with  the  database.  The  implementation 
was  consistent  with  the  GCC  architecture  and  used  several  commercial-off-the-shelf 
(COTS)  products  as  components....  The  results  of  the  GCC  Phase  2  are  extremely 
promising  toward  the  concept  feasibility  of  integrating  large  software  components  for 
application  in  the  Command  Center  domain.” 

PRISM  has  an  ambitious  goal  of  fleshing  out  a  real  command  center  generic  architecture.  It 
pnqioses  to  provide  a  uso*  with  80%  of  the  required  resources  to  produce  a  new  command  center 
as  well  as  information  on  acquiring  or  producing  the  remainder.  The  CARDS  library  models  are 
incrementally  encoding  and  disseminating  information  generated  by  PRISM. 

33  PRISM  Documentatitm  Modd  Access 

Upon  logging  onto  AFS  and  issuing  the  command  "rungb",  the  Graphical  User  Interface  (also 
called  the  library  launcher)  appears.  To  access  the  1.0: 

1.  Through  the  "Choose  a  Library"  pull-down  menu,  select  the  library  you  want,  e.g., 
TRISM  Documentation  vl.O" 
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2.  Through  the  "Choose  a  Command"  pull-down  menu,  select  the  "Enter  Library" 
option. 

3.  Select  the  "OK"  buttcxi  to  enter  the  desired  library. 

Release  Notes  and  Help  are  available  and  are  specific  to  each  library. 


3.4  PRISM  Documoitation  Library  Model  Structure 


The  documents  contained  in  the  PDL  are  the  fonnal  deliverables  firom  contractors  working  on 
PRISM  and  consist  mainly  of  Contract  Data  Requirements  List  (CDRL)  items  and  other  technical 
reports  delivered  to  the  Government  under  the  contract’s  Data  Accession  List  The  PRISM 
documentation  was  divided  into  four  areas  of  concentration:  Command  Center  Architecture 
Reports,  Command  Center  Demonstration  Reports,  PRISM  Process  Reports,  and  Command 
Center  component  product  assessment  reports  (see  Figure  3-1).  These  areas  of  concentration 
fenn  the  first  level  of  PDL  specialization  detail. 

The  PDL  maintains  the  same  look  and  feel  as  the  CCL.  Upon  entering  the  PDL,  the  view  of  the 
PDL  is  of  the  root  node,  prismjiocumentation,  ar^  its  categories  and  individuals. 

ASen  and  PostScript  versions  of  the  documents  contained  under  this  structure  are  available  for 
extraction;  however,  only  the  ASCII  versions  of  the  documents  may  be  viewed  through  the  RLF 
at  this  time. 


Figure  3-1  PRISM  Documentation  Model  Top-Level  View. 
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3.4.1  Ardiitecture  Report 


PRISM  Architecture  Reports  (see  Figure  3-2)  represent  the  PRISM  GCC  architecture  (GCCA) 
and  serve  as  an  imptementadon  framework  for  future  development  of  command  center  systems. 
The  PDL  provides  the  most  current  version  of  the  Architecture  Report 

The  purpose  of  this  report  is  to  represent  the  PRISM  GCXIA,  which  is  intended  to  serve  as  an 
implementation  framework  for  future  development  of  command  center  systems.  [PRISM93a] 


Figure  3-2  Architecture  Report  and  Its  Child. 


3.4.2  Demonstration  Report 


Every  three  months  PRISM  produces  a  CKXIA  demonstration  including  emphasis  on  new 
capabilities  being  added  since  the  previous  quarterly  demonstration.  A  report  is  generated 
documenting  the  envircmment,  results  of  those  demonstratitms,  and  summarizes  the  PRISM 
capabilities  added  to  the  GCCA.  During  PRISM*s  first  year,  the  demonstration  reports  were 
called  Proof  of  Concept  (POQ  Repents.  They  have  since  been  named  Quarterly  Demonstration 
Reports  (QDRs).  (see  Figure  3-3) 
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3.4  J.1  July  1992  Proof  of  Concept  Prototype  Report 

The  July  1992  PRISM  POC  Prototype  Report  documents  the  GCCA  requirements  and  system 
design.  This  report  also  contains  the  System  User’s  Manual  and  the  Version  Description  for  the 
GC^  baseline  demonstrated  in  July  1992.  This  report  provides  potential  GCCA  users  with 
descriptions  of  the  software  components,  design  structure,  lessons  learned,  interface  definitions, 
known  deficiencies,  recommended  improvements,  and  system  user  instructions.  [PRISM93b] 

3.4.2  J  November  1992  Proof  of  Concept  Prototype  Report 

The  November  1992  PRISM  POC  Prototype  Reptvt  presents  a  new  GCC  prototype  baseline 
providing  significant  increased  functionality  over  previous  prototypes.  This  series  of  baselines 
is  intended  to  serve  as  an  implementation  frameworic  for  command  center  development;  its 
primary  objective  is  to  validate  the  concept  of  developing  command  center  systems  through  the 
integration  of  off-the-shelf,  reusable  software  components. 

3.43  Quarterly  Demonstration  Report  (QDRs) 

The  PRISM  QDRs  (Releases  2.0  and  2.1)  are  generated  to  document  the  results  of  each  quarterly 
demonstration  and  summarize  the  capabilities  PRISM  added  to  the  GCCA. 

3.4.4  Process  Report 


This  category  of  PRISM  documentation  includes  publication  of  one  time  CDRLs  covering  the 
details  of  the  PRISM  process  (see  Figure  3-4). 


Figure  3-4  Process  Report  and  Its  CSiildren. 
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3.4.4.1  Five  Year  Plan 

PRISM’S  Five  Year  Plan  is  intended  to  serve  as  a  management  tool  and  assist  key  staff  personnel 
by  identifying  and  docunienting  critical  program  objectives  and  associated  dates  and  milestones 
for  accomplishing  them.  The  Plan  was  initially  created  in  March  1992  and  has  undergone 
periodic  updates  and  revisions  to  arrive  at  this  deliverable  format  Additionally,  this  Plan  assists 
in  detailed  demonstration  planning,  resource  identification  and  allocation,  and  tracking  future 
technology  trends.  [PRISM93f| 

3.4.4.2  Qualification  Methodology  Report 

This  Report  describes  a  set  of  procedures  and  criteria  for  qualifying  software  components  for 
incorporation  in  the  generic  command  center.  [PRISM93g] 


3.4.43  Reusability  Process 

The  PRISM  Reusability  Process  defines  a  set  of  procedures  and  work  items  for  identifying, 
evaluating,  preparing  and  maintaining  reusable  software  components  for  PRISM.  [PRISM93h] 


3.43  Product  Assessment  Report  (PARs) 


In  accordance  with  the  PRISM  Qualification  Methodology  and  the  PRISM  Product  Examination 
Process,  PRISM  produces  PARs  (see  figure  3-5)  on  each  product  included  in  the  quarterly 
demonstrations.  Hiese  reports  summarize  the  capabilities  of  each  of  the  products  assessed. 

These  components  were  considered  for  evaluation,  but  not  necessarily  at  the  same  level  of 
effort:  Operational  Support  System  Joint  Automated  Message  Editing  System  (OSS-JAMES), 
Stand-Alone  JAMES,  Logicon  Message  Dissemination  System  (LMDS),  Joint  Message  Analysis 
and  Processing  System  (JMAPS),  Sybase,  Oracle,  Interbase,  Ingres,  Informix,  DeLorme’s  XDK, 
Prior  Data  Science’s  InterMAPhics,  Rome  Laboratory’s  Common  Mapping  Toolkit  (CMTK), 
ARC/INFO,  DEC^essageQ,  Trusted  Information  System’s  (TIS)  Trusted  Xenix  (with  Ethernet 
LAN  interfaces,  DoD  standard  protocols  (TCP/IP)  and  network  applications  (FTP)),  Harris  Night 
Hawk,  SEI  MTV,  UNIX  tools  lex  and  yacc,  SunNet  Manager  (SNM)  product,  SecureWare’s 
Compartmented  Mode  Workstation  (CN^4-)  for  A/UX,  Trusted  Information  System’s  (TIS) 
Trusted  Xenix  B1  platform,  AT&T’s  B1  System  V  MLS  (running  on  a  3B2),  Ultrix  MLS+, 
Vodix  Secure  LAN  (VSLAN)  and  Boeing  MLS  LAN. 
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Hgure  3-5  Product  Assessment  Report  and  Its  Children. 


3.4^.1  AMHS  Evaluation 

This  Report  describes  Automated  Message  Handling  System  (AMHS)  product  assessments 
performed  on  products  intended  for  use  in  the  PRISM  GCCA,  which  provides  the  technologies 
and  components  needed  to  support  specific  command  center  objectives.  [PRISM93i] 


3.4^^  Contessa  Evaluation 

Contexture  Systems’  (Contessa  is  an  application  develt^ment  environment  that  creates  graphical 
user  interface  (GUI)  based  applicaticms  which  integrate  data.  [PRISM93j] 
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3AJS3  DBMS  Evaluation 

This  Report  documents  the  products  being  assessed  as  candidates  fm*  the  Database  Manager 
(DBM)  component  of  the  PRISM  GCCA.  The  DBM  consists  of  the  server  and  its  interface  to 
the  databases  it  controls.  This  Report  includes  the  Sybase  product  assessment  through  integration 
in  the  GCC  environment  and  the  screening  of  the  Oracle,  Interbase,  Ingres  and  Infomux  products. 
Sybase  met  the  basic  GCCA  requirements.  [PRISM93k] 

3.4.5.4  GIS  Evaluation 

This  Report  documents  the  product  assessments  of  various  Geographic  Information  Systems 
(GIS).  [PRISM931] 

3.4.5.5  Interprocess  Communicatim  (IPC)  Evaluation 

This  Report  documents  the  products  being  assessed  as  candidates  for  the  IPC  component  The 
IPC  provides  a  common  application  program  intmface  (API)  of  communication  services  across 
heterogeneous  operating  systems  and  networks.  [PRISM93m] 

3.4.5.6  Low  to  High  Guard  Evaluation 

This  repon  documents  a  security  mechanism  that  only  allows  file  transfer  of  information  firom 
one  level  of  security  classification  to  the  next  higher  level  of  security  classification. 

3.4.5.7  MTV  Evaluation 

Tliis  Report  documents  the  products  being  assessed  as  candidates  for  the  Message  Translator  and 
Validator  (MTV)  component  of  the  PRISM  GCCA.  The  MTV  component  performs  the  translation 
and  validation  of  both  character  and  bit  based  messages,  and  the  update  of  the  mission  database 
and  the  mission  application  displays. 

3.4.5.8  Network  Monitor  Evaluation 

The  Network  Monitor  and  Control  function  enables  maximum  performance  and  utilization  of 
resources  from  the  IPSs  and  communication  services.  [PRlSM93p] 

3.4.5.9  Night  Hawk  Guard  Evaluation 

This  Report  documents  the  produa  assessment  of  the  Low>to-High  Message  Guard  Platform 
component  [PRISM93q] 

3.4.5.10  Secure  LAN  Evaluation 

This  Report  describes  the  assessment  process  of  two  LAN  cennponents:  the  VSLAN  through  the 
integration  phase  and  the  Boeing  MLS  LAN  through  the  screening  phase. 

3.5  Future  Directions/Enhancements 
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3^.1  Structural  Changes 

The  main  thrust  of  future  development  of  the  PDL  will  be  the  addition  of  PRISM  command  center 
comptment  demonstrations  using  a  software  tool  called  Screenplay.  In  these  demmistrations, 
command  center  software  will  be  displayed  as  a  series  of  static  views  ("snap  shots")  of  the 
actual  ruiming  of  the  software. 

3.5.2  Action  Changes 

The  addition  of  system  demonstrations  using  the  ScreenPiay  utility  will  warrant  the  addititm  of  a 
run_demonstrati(m  action  to  the  library.  It  will  be  placed  under  the  perform.action  menu  optitm 
appearing  after  clicking  the  desired  node. 
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APPENDIX  B  •  Glossary  of  Terms  and  Acronyms 


B.1  To-ms 
action 


aggregation 


application 


automated  message  handling 


A  mechanism  permitting  a  user  of  the  RLF  graphical 
browser  to  invoke  calls  to  the  underlying  operating 
system,  including  invoking  other  tools. 

Relationship  between  AdaKNET  concepts  which  express 
attributes,  characteristics,  features  (as  the  term  is  used  in 
FODA),  functional  capabilities,  requirements  or  metrics; 
that  is,  any  relationship  existing  between  two  concepts 
which  is  nm  a  specialization  relationship. 

A  system  providing  a  set  of  general  services  for  solving 
some  type  of  user  problem. 

Processing  of  strictly  formatted  messages. 


category  •  see  concept 

class  -  see  concept 


command  center 


ccnnponent 


concept 


converged 


domain 


feature 


A  facility  from  which  a  commander  and  her/his  repre¬ 
sentatives  direct  operations  and  control  forces.  It  is  or¬ 
ganized  to  gather,  process,  analyze,  display  and  dissem¬ 
inate  planrung  and  operational  data  and  to  perform  other 
related  tasks. 

A  set  of  reusable  resources  related  by  virtue  of  being 
the  inputs  to  various  stages  of  the  software  design  life- 
cycle,  including  requirements,  design,  code,  test  cases, 
documentation,  etc.  Components  are  the  fundamental  el¬ 
ements  in  a  reusable  software  library. 

An  atomic  unit  of  the  AdaKNET  knowledge  representa¬ 
tion  scheme,  representing  an  idea  or  thing,  also  known 
as  a  generic  concept,  a  category  or  a  class. 

Said  of  an  AdaKNET  role  range  for  which  the  miiumum 
and  maximum  have  been  set  to  the  same  value. 

An  area  of  activity  or  knowledge  containing  applicatitxis 
sharing  a  set  of  commtm  ciq>abilities  and  data. 

A  prominent  or  distinctive  user-visible  aspect,  quality,  or 
characteristic  of  a  software  system  or  systems. 


PagcB-i 


STARS- VC-B015/000/00 


3  December  1993 


filler 


generic  architecture 


individual 


individuation 


inferencer  (Also  called  rule-base) 


inherit 

inheritance 

instance 


A  role  used  only  between  individuals.  The  filler  of  an 
individual’s  relationship  must  adhere  to  the  relationship’s 
restrictions.  Both  the  owner  and  the  ’filler’  must  be 
individuals. 

A  collection  of  high-level  paradigms  and  constraints  char¬ 
acterizing  the  commcxiality  and  variances  of  the  interac¬ 
tions  and  relationships  between  the  various  components 
in  a  system. 

A  knowledge  representation  of  the  reusable  compcment 
of  the  library.  An  AdaKNET  term  for  representing  a 
specific  instantiatitm  of  a  concept.  Also  known  as  an 
individual  concept,  an  object  or  an  instance. 

The  relationship  between  an  individual  to  its  subsuming 
concept  Indicates  that  an  individual  is  an  actual  instance 
of  the  idea  represented  by  the  concept 

A  mechanism  using  existing  facts  and  rules  about  the 
elements  of  a  model  to  poform  reasoning  about  that 
model  and  deduce  new  facts  and  rules. 

-  see  inheritance. 

A  mechanism  whereby  classes  make  use  of  the  proce¬ 
dures,  attributes,  and/or  data  defined  in  other  classes. 

-  see  individual. 


intermediate  levels  of  specialization  Concepts  that  partition  a  category  into  subcategories. 


library  model 
library  modeling 


model-based  library 


multi-level  security 


A  model  representing  the  domain  components  and  the 
relationships  between  them. 

The  process  of  building  a  library  model  that  accurately 
reflects  the  functionality  and  structure  of  the  target 
domaitL 

A  library  organized  around  the  principle  that  what  matters 
in  a  repository  is  the  context  in  which  reusable  software 
components  ate  used  and  the  relationships  among 
components.  The  focus  of  a  model-based  library  is  the 
model  (requirements,  architectures,  design  decisions  and 
rationales)  and  the  software  implementing  these  models. 

Information  processing  and  communications  allowing 
two  or  more  classification  levels  of  information  to  be 
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(role)  name 

object 
(role)  range 

role 

role  restriction 

rule-base  (Also  called  inferencer) 

software  architecture 


specialization 

subsume 


(role)  type 


processed  simultaneously  within  the  same  system  when 
some  users  are  not  cleared  for  all  levels  of  information 
present 

Refers  to  the  name  of  an  AdaKNET  aggregation  relation¬ 
ship. 

-  see  individual. 


The  number  of  simultaneous  copies  consisting  of  an 
AdaKNET  aggregation  relationship. 

An  AdaKNET  term  referring  to  an  aggregation  (’consists 
of)  relationship  between  two  concepts. 

Refers  to  an  inherited  AdaKNET  aggregation  relationship 
which  is  narrowed  at  the  inheriting  concept  either  by 
further  restricting  the  range  or  by  further  resnicting  the 
type. 

A  collection  of  rules  about  the  elements  of  a  domain. 
A  rule  describes  the  relationships,  requirements  and 
constraints  among  components. 

High-level  paradigms  and  constraints  characterizing  the 
structure  of  operations  and  objects,  their  interfaces  and 
ccmtrol  to  support  the  implementation  of  applications  in 
a  domain.  Includes  a  description  of  each  software  cmn- 
ponent’s  functionality,  name,  parameters  and  their  types, 
and  a  descriptitxi  of  the  components*  interrelationships. 

The  act  of  declaring  that  one  concept  represents  a 
narrowing  of  the  idea  represented  by  another  concept 

Having  an  "is-a"  relation  with  a  concept  where  the 
subsuming  concq)t  is  a  larger  and  more  abstract  category 
(eg  .,  IS  a  and  is  a  Z  therefore  T*  subsumes  and 
Y). 

The  allowable  range  of  values  of  an  AdaKNET  aggrega¬ 
tion  itde. 


B  J  Aaronyms 

ACC  Air  Combat  Command 

AMHS  Automated  Message  Handling  System 


PagcB-3 


STARS-VC-B015AXXV00 


3  December  1993 


API 

Application  Interface 

ARPA 

Advanced  Research  Projects  Agency 

CARDS 

Central  Archive  for  Reusable  Defense  Software 

CCL 

Command  Center  Library 

CDRL 

Contract  Data  Requirements  list 

COTS 

Commeicial-Off-The-Shelf 

DBM 

Database  Management 

DBMS 

Database  Management  System 

DMQ 

DECmessageQ 

FTP 

File  Transfo*  Protocol 

GCC 

Generic  Command  Center 

GCCA 

Generic  Command  Center  Architecture 

GIS 

Geographic  Information  System 

GOTS 

Govcmment-O£f-The-Shelf 

GUE 

Grtqihical  User  Interface 

IPC 

Interprocess  Communications 

IPS 

Information  Processing  Subsystem 

JMAPS 

Joint  Message  Analysis  and  Processing  System 

LAN 

Local  Area  Netwoik 

LMDS 

Logicon  Message  Dessination  System 

MLS 

Multi-Level  Security 

MTV 

Message  TranslatOT  Validator 

NASA 

National  Aercmautics  and  Space  Agency 

OSS-JAMES 

Operational  Supptnt  System  Joint  Automated  Message 
Editing  System 

PAR 

Product  Assessment  Report 

PDL 

PRISM  Documentation  Library 
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POC 

PRISM 

QDR 

RLF 

sm 

SNM 

STARS 

TCP/IP 

ns 

VSLAN 


Proof  Of  Concept 

Portable,  Reusable,  Integrated  Software  Modules 
Quarteily  Demonstration  Report 
Reuse  Library  Framework 
Software  Engineoing  Institute 
SunNet  Manager 

Software  Technology  for  Adaptable,  Reliable  Systems 

Transmission  Communications  Protocol/Interface  Proto¬ 
col 

Trusted  Information  System 
Verdix  Secure  Local  Area  Network 


STARS-VC-B015/000/00 


3  December  1993 


APPENDIX  C  >  Library  Actions 

Actions  can  be  any  executable  command  or  script  If  an  ’action’  is  included  at  a  concept  the 
phrase  Perform  Action  appears  on  the  pop-up  menu  when  the  user  chooses  the  node  representing 
that  concept  Another  pop-up  menu  appears  when  Perform  Action  is  chosen.  This  menu  displays 
the  action(s)  available  at  that  concept  If  there  are  no  actions  at  the  concept  the  Perform  Action 
optitm  is  not  presented  as  a  menu  choice. 

The  list  of  invocable  actions,  a  short  descriptitm.  and  the  concepts  at  which  those  actions  can 
currently  be  called  follows: 

•  Provide  Description  —  Displays  the  Description  file  for  a  particular  node.  The 
preview  utility  is  used  to  display  the  Description  file.  It  is  available  at: 

•  architecture.report 

•  demonstration_report 

•  process_repott 

•  product_assessment_report 

•  proof_of_concept_report 

•  quanerly.demonstration.report 

•  prism.documentation 

•  View  Contents  -  Views  ASCII  text  version  of  the  document  The  preview  utility  is 
used  to  display  the  ASCII  file,  which  is  in  the  same  directory  space  as  the 
PostScript  file  and  is  extractable: 

•  GCC_architecture_report 

•  POC„July_92 

•  POC_Nov_92 

•  QDR_release_2_0 

•  QDR_rclease_2_l 
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•  Reuse_piocess 

•  Secure_lan_eval 

•  Nighthaw*'  ^uard_cval 

•  Nctworic_moniior_cval 

•  MTV_eval 

•  Low_to_high_guard_eval 

•  IPC_cval 

•  AMHS_cval 

•  G>ntessa_eval 

•  DBMS_eval 

•  GIS_eval 

•  Extract  Contents  -  Extracts  the  contents  of  directories  and/or  files  from  an  RLF 
Library  to  a  user  specified  target  directory.  It  is  available  at  concepts: 

•  GCC_aichitecture_rer*ort 

•  POC_July_92 

•  POC_Nov_92 

•  QDR_release_2_0 

•  QDR_release_2_l 

•  Five_year_plan 

•  Qual_methodology_rBpOTt 
’  Reuse.j)rocess 

•  Seciire_lan_eval 

•  Nighthawk_guard_eval 


PageC-2 


STARS-VC-BOISAXXVOO 


3  December  1993 


•  Network_monitor_eval 

•  MTV_eval 

•  Low_to_high_guard_eval 

•  IPC_eval 

•  AMHS_eval 

•  C(mtessa_eval 

•  DBMS.eval 

•  GIS_eval 

•  Display  Abstract  -  Displays  an  Abstract  outlining  the  features  and  capabilities  of  an 
asset  It  is  available  at  concept: 

•  G(Xl_arcliitecturB_rcport 

•  POC_July_92 

•  POC_Nov_92 

•  QDR_release_2jO 

•  QDR_releasc_2_l 

•  Five_year_plan 

•  QuaI_mediodology_report 

•  Reuse_proce5S 

•  Secure_lan_eval 

•  Nighthawk;_guard_eval 

•  Netwoik_inonitor_eval 

•  MTV_eval 

•  Low_to_high_guard_eval 
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•  IPC_cval 

•  AMHS_eval 

•  Contessa_eval 

•  DBMS_cval 

•  GIS_eval 
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